Skip to content

Conversation

@jsntcy
Copy link
Member

@jsntcy jsntcy commented Apr 10, 2020

Description of PR (Mandatory)
This PR does the following things to support track1 and track2 mgmt SDK side by side:

  • Integrate azure-mgmt-core 1.0.0
  • Authentication
    • add get_token() callback to support track2
  • Config
    • Use client_kwargs to replace client.config in track2
  • Error handling
    • Also support HttpResponseError AzureError from track2
  • LRO poller
    • Also support LRO poller from track2
  • Paging
    • Also support paging from track2
  • Remove unexpected arguments as track2 will raise exception when it finds unknown arguments.
    • remove raw argument for no wait and pass raw explicitly in method if necessary.
    • remove parameters argument for generic update and use actual arguments in SDK instead.

Testing Guide

  • All CLI automation tests pass.
  • Use CodeGen v2 to generate CLI extensions to test.

History Notes:
(Fill in the following template if multiple notes are needed, otherwise PR title will be used for history note.)

[Component Name 1] (BREAKING CHANGE:) (az command:) make some customer-facing change.
[Component Name 2] (BREAKING CHANGE:) (az command:) make some customer-facing change.


This checklist is used to make sure that common guidelines for a pull request are followed.

@jsntcy jsntcy changed the title [Core] Support track2 mgmt SDK in CLI [Core] Support track1 and track2 mgmt SDK side by side in CLI Apr 10, 2020
@jsntcy jsntcy requested a review from lmazuel April 10, 2020 07:48
@yonzhan yonzhan added this to the S168 milestone Apr 10, 2020
@yonzhan
Copy link
Collaborator

yonzhan commented Apr 10, 2020

add to S168

from msrestazure.azure_exceptions import CloudError

response = sdk_no_wait(True, client.generate)
response = client.generate(raw=True)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so. Is sdk_not_wait useless?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, sdk_not_wait is still useful for LRO as it will set "polling" to false if no_wait is true.
But here it should not use sdk_no_wait as it's not a LRO (I checked the SDK method.)
'raw' is another story which is different from LRO, so it should not be set in sdk_no_wait.

All other places I replace 'sdk_no_wait' with 'raw=True' actually are bug fix for those modules.


In reply to: 406657030 [](ancestors = 406657030)

from msrestazure.azure_exceptions import CloudError

response = sdk_no_wait(True, client.generate)
response = client.generate(raw=True)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can split the migration of advisor and backup to a different PR?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can split it to another PR.


In reply to: 406657692 [](ancestors = 406657692)

"https://docs.microsoft.com/cli/azure/query-azure-cli?view=azure-cli-latest")
return 1
if isinstance(ex, (CLIError, CloudError, AzureException)):
if isinstance(ex, (CLIError, CloudError, AzureException, HttpResponseError, AzureError)):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional: HttpResponseError being a subclass of AzureError, you could simply catch AzureError

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, will update in next commit.


In reply to: 406869816 [](ancestors = 406869816)

Copy link
Member

@lmazuel lmazuel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Core changes LGTM, won't comment on advisor/backup, as suggested by @jiasli I would do atomic PR and split them, up to you.

Copy link
Member

@qianwens qianwens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

from msrestazure.azure_exceptions import CloudError

response = sdk_no_wait(True, client.generate)
response = client.generate(raw=True)
Copy link
Member Author

@jsntcy jsntcy Apr 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Prasanna-Padmanabhan,
Here we pass raw=True in method instead of using sdk_no_wait (actually it's not correct to use sdk_no_wait before as client.generate is not a long running operation.), please help confirm this change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have the necessary knowledge to sign off on this change. If all existing tests are passing, then you can go ahead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Prasanna-Padmanabhan, thanks for your confirm. All existing tests are passing, so we'll commit this change.

client_kwargs['headers'] = headers

if 'x-ms-client-request-id' in cli_ctx.data['headers']:
client_kwargs['request_id'] = cli_ctx.data['headers']['x-ms-client-request-id']
Copy link
Contributor

@Juliehzl Juliehzl Apr 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some questions here:

  1. request_id is required for client?
  2. Should we use x-ms-request-id?
    x-ms-request-id: This is a common response header that contains a unique identifier for the current operation, service generated.
    x-ms-client-request-id: Optional. Contains a unique ID provided by the client to identify the specific request.
    It looks x-ms-client--request-id is right. #WontFix

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually request_id will be set to "x-ms-client-request-id" in request header, you can check the code in azure core below:

def on_request(self, request):
# type: (PipelineRequest) -> None
"""Updates with the given request id before sending the request to the next policy.

    :param request: The PipelineRequest object
    :type request: ~azure.core.pipeline.PipelineRequest
    """
    request_id = unset = object()
    if 'request_id' in request.context.options:
        request_id = request.context.options.pop('request_id')
        if request_id is None:
            return
    elif self._request_id is None:
        return
    elif self._request_id is not _Unset:
        request_id = self._request_id   # type: ignore
    elif self._auto_request_id:
        request_id = str(uuid.uuid1())  # type: ignore
    if request_id is not unset:
        header = {"x-ms-client-request-id": request_id}

In reply to: 407376852 [](ancestors = 407376852)

@jsntcy jsntcy force-pushed the azure-core-preview branch from da45cca to c924cf4 Compare April 13, 2020 09:26
@yonzhan yonzhan merged commit 62fdf0e into dev Apr 14, 2020
@jiasli jiasli deleted the azure-core-preview branch November 24, 2020 08:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants